NB: These tips are for XP, for Win7/Vista/2008 see
http://www.speedguide.net/faq_in_q.p...ry=100&qid=303
Or see the post further down for the quick version, but you will need to follow the ping guide below to find the value for yourself.
Very basic networking blurb to set the scene:
As default all windows/linux installations have their MTU(Max Transferable Unit) size set to 1500 bytes per TCP data packet, this is the maximum possible MTU. This at best contains 1472 bytes of actual data and the remaining 28 bytes is the IP+ICMP header. Which is fine under normal circumstances.
Now, the problem with Uthgard is that for some reason if the size of a packet sent to their server is anywhere between 1493 and 1500 it just drops the packet(losses it, hence packet loss) this is pretty inexcusable imo although their server host is to blame not them i'd imagine.
You can see this for yourself by doing a simple ping test.
Open a cmd prompt and do:
ping uthgard.game-server.cc -f -l 1472
NB: why 1472 and not 1500? well because 1472 is the maximum data size, 28 bytes will automagically be added to that containing IP+ICMP info.
You'll see all you get back is:
Pinging uthgard.game-server.cc [88.198.56.21] with 1472 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 88.198.56.21:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
You don't need to wait for the whole thing to finish on each try, if you don't get a response within 1 second it's gonna fail so just press CTRL+C to break out of it.
The 1st normal working response i got was when i used only 1464 bytes of data:
Pinging uthgard.game-server.cc [88.198.56.21] with 1464 bytes of data:
Reply from 88.198.56.21: bytes=1464 time=56ms TTL=120
Reply from 88.198.56.21: bytes=1464 time=56ms TTL=120
Reply from 88.198.56.21: bytes=1464 time=56ms TTL=120
Reply from 88.198.56.21: bytes=1464 time=56ms TTL=120
Ping statistics for 88.198.56.21:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 56ms, Maximum = 56ms, Average = 56ms
1464+28 = 1492, which for Uthgard is the biggest packet it will handle before it starts dropping them.
Biggest isn't always best though, there are far more advanced tests we could run to determine the optimal MTU(and other settings like RWIN) size for Uthgard to get the best response times but a simple MTU change is enough to solve the major issues. And for your connection through your ISP you may still need to lower it further to stop fragmentation. When using the above ping command if your packets need to be fragmented you'll see this message:
Packet needs to be fragmented but DF set.
Which is bad, so reduce that number and try again basically until you find the biggest packet size your connection can handle before fragmentaion. Once you have that magic number add 28 to it and that is the biggest size you should set your MTU to.
There is a tool which will calculate the the best MTU for a given destination, but with Uthgard being a bastard it'll freak out ;p but you can use the tool to set your MTU, plus you may need to alter the configuration on your router.
http://www.speedguide.net/files/TCPOptimizer.exe
In there pick your network adapter on the General settins tab, If you know what speed your connection actually runs at enter it in the Connection Speed area, but ignore the rubbish that your ISP tells you about how fast it is, and find out your actual speed as it can vary wildly:
http://www.speedguide.net/speedtest/
Click on custom settings and then enter the MTU which you found for Uthgard earlier.
Click on apply and then restart your machine and see how it goes. You may like me need to also adjust this number on your router, details should be in the manual but it's normally pretty easy and obvious after you've connected to your routes configuration page.
A lot of people will automatically just set their MTU to either 1478/1468/1458 and even 1430. 1470s(ie 1472) are nice in general, and will avoid any fragmentation problems.
Uthgard basically buckles on you at times because normally the data your client sends back to it doesn't get near the limit when people are just moving around etc, but when in RvR with lots of people around and spells flying about it then hits the old 1492+ packet size and that's why I and many others experience the horrible packet loss. Most people i think will just attribute to being lag because it looks just like lag, but in reality it's far worse as your data isn't even being accepted by the server which means you have to spam your spell buttons to actually make sure they fire, which in turn can make it worse heh.
I think that's about everything i had to say on this for now and hopefully it'll help a few people out, i'll be starting myself off at 1492 and will work my way down if needed. I also ran these tests at a non-prime time so the number could change, but shouldn't.
Even if you don't think you've noticed any issues it's worth keeping the ingame performance counter on anyways to see if you are effected using alt+p, the middle one is packet loss.